I don't know... this approach feels too annoying. Just look at the hello example. It's very trivial package, but there already you get warnings for many packages that intuitively don't much relate to the package. Also, it will bother on every evaluation, i.e. any time it's used; that's just not useful IMHO.

Maybe in some far-away future when the maintainers field is used very differently than nowadays. Another common issue is that one or more maintainers are listed but none has done anything around the package for years.

Maybe instead we could add some easy way that allows you to enable this if you want. So you can easily check your own derivations. Dont know how to do this exactly though

Maybe instead we could add some easy way that allows you to enable this if you want. So you can easily check your own derivations. Dont know how to do this exactly though (~@mohe2015)

I've now gated this behind a new showDerivationWarnings config option:

ckie@cookiemonster ~/git/nixpkgs -> nix-build --expr '(import ./. { config = {showDerivationWarnings = true;};}).hello'
trace: Package python3-minimal-3.9.10 in /home/ckie/git/nixpkgs/pkgs/development/interpreters/python/cpython/default.nix:491 has no maintainers, continuing anyway.
[..snip..]
/nix/store/g124820p9hlv4lj8qplzxw1c44dxaw1k-hello-2.12

I don't know... this approach feels too annoying. Just look at the hello example. It's very trivial package, but there already you get warnings for many packages that intuitively don't much relate to the package. Also, it will bother on every evaluation, i.e. any time it's used; that's just not useful IMHO.

Well, if we want to get closer to addressing the considerable amount of orphans we need something like this.

Maybe in some far-away future when the maintainers field is used very differently than nowadays. Another common issue is that one or more maintainers are listed but none has done anything around the package for years.

Strawman? Addressing everything in one PR is not feasible.

Please add to pkgs/top-level/config.nix.

See #166792 #171163

(@roberth)

Would you be open to a PR that documents all the other missing options I can think of, or is that already in the works?

@ckiee I don't really have time for "big" projects, so that would be very much appreciated.

i'll add allowUnfree there

EDIT: #171248

Turning that on right now.

Not sure about the valid changes mixed in here.

valid is not exposed as a public API and breaking the one other relevant open PR seems unlikely and is not a blocker regardless. Hence this is a moot point.

Please at least split the valid change into a different commit, and reconsider making a separate PR for it.

I'm afraid you're a bit late for a separate PR (note how far this one has gone already) but I have split it into three commits with nicer, more detailed commit messages.

Also I just noticed there's merge conflicts again, on that.

Good enough for me, thanks ✨ :

@Mindavi Merge after Ofborg's happy?